The present invention relates in general to the field of communications and more particularly to messaging between client devices and servers over multiple wireless networks that use different access protocols.
Recent advances in hardware and communication technologies have brought about an era of client computing over wired and wireless networks. The proliferation of powerful notebook computers and wireless client devices promises to provide client end users with network access at any time and in any location over various networks, including the Internet. This continuous connectivity allows users to be quickly notified of changing events, and provides them with the resources necessary to respond in realtime even when in transit. For example, in the financial services industry, online traders and financial professionals may be given the power to access information in realtime, using wireless client devices.
Conventionally, however, developers of complex, wireless messaging solutions have been forced to develop applications that are specific to various device types and network access protocols in diverse enterprise architectures and platforms. In other words, conventional client computing solutions have been largely platform-specific, network-specific, or both. For example, messages may be generated by a wide variety of applications running on a wide variety of client devices, such as Palm computing platform devices, Windows CE devices, paging and messaging devices, laptop computers, data-capable smart phones, etc. Depending on the type of network used by service providers, the client-generated messages may be transported over networks having various access protocols, such as, e.g., Cellular Digital Packet Data (CDPD), Mobitex, dial-up Internet connections, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), and ReFlex. As a result, current developers of client computing solutions must have intimate knowledge of specific network characteristics including, e.g., wireless network characteristics, protocol environments, and wireless links channel characteristics. Therefore, there exists a need to simplify wireless client and server application development environments to support the wide variety of device and network dependent architectures.
Messaging Application Programming Interface (MAPI) is a messaging architecture and an interface component for applications such as electronic mail, scheduling, calendaring and document management. As a messaging architecture, MAPI provides a consistent interface for multiple application programs to interact with multiple messaging systems across a variety of hardware platforms. MAPI provides cross platform support through such industry standards as Simple Mail Transfer Protocol (SMTP), X.400 and common messaging calls. MAPI is also the messaging component of Windows Open Services Architecture (WOSA).
Accordingly, MAPI is built into such operating systems as, e.g., Windows 95, Windows 98, Windows NT and Windows 2000, available from Microsoft Corporation of Redmond, Wash., U.S.A. and can be used by 16-bit and 32-bit Windows applications. For example, a word processor can send documents and a workgroup application can share and store different types of data using MAPI. MAPI separates the programming interfaces used by the client applications and the service providers. Every component works with a common, Microsoft Windows-based user interface. For example, a single messaging client application can be used to receive messages from fax, a bulletin board system, a host-based messaging system and a LAN-based system. Messages from all of these systems can be delivered to a single xe2x80x9cuniversal inbox.xe2x80x9d
Transmission Control Protocol (TCP) is a transport layer protocol used by an application in one host to communicate with an application in another host. This is accomplished by services provided by the protocol layers beneath the transport layer in both hosts. As a connection-oriented protocol TCP requires the establishment of a connection between the two hosts before two applications are able to communicate. TCP manages the connection and once both applications have communicated all required information between themselves the connection is released as if the connection is two simplex connections as opposed to a single duplex connection. The information is transferred between applications on different hosts is a byte stream. The transport layer hides message transfer details such as segmentation, ordering and duplication from the applications and provides end-to-end acknowledgement.
The Internet Protocol (IP) layer provides certain services to the transport layer protocol including hiding the details of the physical and data link layers and the services provided by them from the transport layer protocol. The IP layer provides a datagram delivery service. A datagram is a unit of data less than an entire message. A message may be, for example, a file, which may be quite large. Since there is a maximum size for a message (or file), the message may have to be segmented and transferred in smaller units. These smaller units are thus called datagrams. Each datagram is sent over the network as a separate entity and may, in fact, follow separate paths to the destination host. At the destination host, the datagrams are reassembled in proper order (usually in a buffer area) by the transport layer. Each node on the network sends any datagrams on to a next node only considering the final destination and only acknowledges receipt of the datagram to the preceding node. That is, the IP layer does not provide end-to-end acknowledgement. End-to-end acknowledgement is a service of the transport layer protocol. Should any node-to-node acknowledgements not be received by the preceding node, the datagram or datagrams unacknowledged will be retransmitted. The transport layer in the destination host will also acknowledge any duplicated datagrams (else receipt of duplicate datagrams will continue resulting in a clogged network) and ignore them.
Routing between network nodes is accomplished by means of routing tables. These routing tables can be static or dynamic and result in datagrams being forwarded from a source host to a destination host one node at a time. The intermediate nodes are often called xe2x80x9chops.xe2x80x9d
The acronym, TCP/IP, is also used to refer to a five layer protocol model similar to the ISO/OSI seven layer protocol model. The TCP/IP model does not have the equivalent to layers 5 and 6 of the ISO/OSI protocol model. A protocol model defines the protocol layers and the interfaces between the layers. When implemented in software, hardware or firmware or possibly field programmable gate arrays (FPGAs), the implementation provides the actual services. This layered approach allows for ease of upgrading so long as the interface to the layer immediately above or below is not altered. Layering also allows for complete substitution. For example, should a new physical medium become available then so long as the interface between layer two and layer one remain the same, an old physical layer implementation module can be removed and a new implementation module substituted. In the alternative, the new implementation module could be added as another option. That is, the protocol suite defines the rules and the implementation provides the services that allow the communications to take place between applications on different hosts. The implementation of the TCP layer provides for the application to require a certain Quality of Service (QOS) as specified by a set of parameters including but not limited to priority, transmission delay, throughput etc.
Another well-known transport layer protocol is known as User Datagram Protocol (UDP), which is a connectionless transport protocol. The basic data transfer unit is the datagram. A datagram is divided into header and data areas as it is for the IP layer. An additional header over and above the IP header is used. The UDP header contains source and destination addresses (ports), a UDP length field (the length includes the 8 byte header and the data) and a UDP checksum. The UDP data includes the IP header and data. The IP layer supports UDP as a connectionless transport protocol for use in transmitting, for example, one time request-reply type messages or applications where time is of greater importance than accuracy.
TCP is used by applications on different hosts to communicate over a assumed unreliable network. To accomplish such communication much is added to the protocol in order to ensure that the information transferred over the network is valid. This addition has a cost and that cost is increased overhead with the attendant increase in bandwidth. A UDP header is eight bytes, the TCP header is 24 bytes and an IP header is a minimum of 20 bytes. Therefore, UDP/IP headers are a minimum of 28 bytes and TCP/IP headers are a minimum of 44 bytes. This is fairly large in terms of overhead and bandwidth utilization particularly over wireless networks. There are other significant problems with using standard TCP/IP over wireless networks principally in the area of flow control. The UDP/IP protocol combination, while not offering any guarantees to users, is expected to be reliable. Wireless networks tend, however, by their nature to be lossy. Several solutions have been proposed when the network is not homogeneous. That is, when the network has both wireless and wireline portions. One suggestion is to use indirect TCP and another is to use snooping.
Other protocols such as Serial Line IP (SLIP) and Point to Point Protocol (PPP) have been developed. SLIP is not a standard and both are for point to point connections only so are not available for uses in networks. CDPD vendors indicate that they provide an integrated TCP/IP stack but it is not known the cost in terms of bandwidth overhead.
Conventionally, the existing wireless protocols do not provide an end-to-end solution over multiple networks and multiple client devices. Therefore, in addition to the need for a common architecture through a single, user friendly methodology for providing effective and reliable wireless data solutions for hand-held and laptop computing devices, wireless networks, and legacy systems, there also exists a need to efficiently and reliably communicate data using minimum bandwidth.
The present invention features a system, method and computer program product that in an exemplary embodiment is operative to provide a multi-network transport programming interface that can enable client/server applications to be written easily, where such applications can allow client applications running on client devices to communicate messages with server applications across one or more wireless and wire-line networks. Moreover, the present invention in an exemplary embodiment offers features for communicating such messages over wireless networks efficiently, without requiring significant bandwidth, a valuable resource in wireless networks.
Briefly, the present invention in an exemplary embodiment includes a system for communicating messages in a client-server environment over one or more wireless networks that can support different network protocols. In an exemplary embodiment, the system of the invention includes a client device operative to execute a client application, and a back-end server (BES) operative to execute a server application. In an exemplary embodiment, a protocol gateway (PG) can encapsulate an underlying network protocol of the plurality of wireless networks. In an exemplary embodiment, a client application and the server application can communicate messages with each other through the PG independently of the underlying network protocol of the wireless network used for such communication.
Conventional session-based transport protocols (e.g. TCP) are designed for LAN-based systems with little network latency. These session-based transport protocol implementations are extremely chatty and were not designed to consider the amount of bytes sent over the network to maintain the state of a connection.
Advantageously, the present invention, in an exemplary embodiment, features a highly optimized semi-reliable data transport protocol, simple network transport layer (SNTL). The transport protocol implementation, in an exemplary embodiment, can optimize the over the air communication by using a connectionless send and receive mechanism. In addition, or alternatively, in an exemplary embodiment, the present invention can provide multiple compression mechanisms to reduce the amount of information that needs to be sent over the air. In an exemplary embodiment, in order to provide a reliable mechanism over a connectionless environment, the transport protocol implementation can provide for message segmentation and reassembly, message retries, or message ACK and NACK service for each supported wireless network. In an exemplary embodiment, message segments that are not acknowledged by the peer protocol layer within the configurable time frame can be retried automatically by the transport protocol implementation. In order to facilitate the request and provision of services, the interfaces between layers can be clearly defined for peer-to-peer communication between corresponding layers of both sides of a connection. That is, the protocol stack on each side (client and server) can be symmetrical. This can allow two machines to specify how they communicate with one another on a level-to-level basis, rather than having to negotiate one giant protocol for the entire network. This means that logical communications can occur at the peer protocol layer. On the client side for wireless communications this can be called a peer wireless protocol layer. In an exemplary embodiment, the client or server applications do not need to be concerned with segmenting the message and performing message retries. In addition to performing message retries, the transport protocol implementation can support message duplication detection. In an exemplary embodiment, to support this reliable mechanism over a connectionless environment, the transport protocol implementation can add only four to six bytes to each application message. In an exemplary embodiment, SNTL can include a novel and non-obvious hybrid protocol including many of the advantages of TCP but connectionless as is UDP. Further, in an exemplary embodiment, there can be less overhead than is required by conventional TCP.
The present invention, in an exemplary embodiment, can also use a wireless connectivity middle layer gateway, which can be developed using a wireless software development environment. The environment can insulate a developer from the complexities of the underlying details related to devices and protocols.
In an exemplary embodiment, the environment can be packaged, advantageously, as a software development toolkit (SDK). The developer can work at the application layer by using the SDK. The SDK, in an exemplary embodiment, can include, e.g., software libraries for client and/or server application development. The present invention, in an exemplary embodiment, can support solutions and software engineering using technologies such as, e.g., Windows NT/95/98/2000, Open Database Connection (ODBC) compliant databases, Palm OS, and Windows CE client devices, and CDPD, Mobitex and dial-up networks.
Advantageously, wireless technologies and client devices can remain transparent to the data source through the use of client and server application programming interfaces (APIs) that can support multiple operating environments including, for example, Palm OS, RIM, Windows 95, 98, 2000, CE and NT, UNIX, Linux, and other variations of UNIX, etc. These well-defined APIs can use a set of portable class libraries to aid in rapid application development. Access to the intelligent messaging network of the present invention can be via wireless client devices or via a dial-up or leased line or other wireline connection coupled via, e.g., an Internet service provider (ISP), a network service provider (NSP), a private network, or a virtual private network (VPN). That is, enterprise support, can be provided for and to, wireless clients and clients that need to access the intelligent messaging network of the present invention via a wired connection or dial-up line. This latter group of clients can be called Internet proxy clients, i.e., clients that can use a proxy server for access to the Internet. As client devices and wireless network technologies evolve, this system can ensure that data solutions are supported.
An exemplary embodiment of the present invention is directed to a method of providing discovery services for servers during a startup sequence. An exemplary embodiment of the method can include powering on a server in a domain; creating a listener socket for the server to accept coupling requests from other servers; registering server information for the server with a database; searching the database for other registered servers in the domain; establishing a couple to each of the other registered servers in the domain; and verifying validity of the couple to each of the other registered servers including performing a handshake.
In an exemplary embodiment, the server information registered with the database can include an IP address; a listener port; a domain; a version number; or a server type.
In an exemplary embodiment, the establishing step can include: sending a couple message from a coupling server of the other registered servers; receiving the couple message by another server of the other registered servers; verifying a version number of the couple message; verifying that the couple message sent and received is a valid couple message; replying with a reply message to the couple message; or verifying that the reply message contains a valid version number and server type.
In an exemplary embodiment, the establishing step can further include closing the couple if the version numbers are not valid.
In an exemplary embodiment, the establishing step can further include closing the couple if the server type is not valid.
In an exemplary embodiment, the establishing step can further include closing the couple if the reply message is not received within a predetermined amount of time.
In an exemplary embodiment, the method can further include registering a server identifier (ID), a service type, or a message type supported by the server.
In an exemplary embodiment, the server can be a back end server (BES); a proxy gateway (PG); a message router (MR); or an HTTP Proxy BES.
In an exemplary embodiment, a method for handling coupling race conditions is set forth including accessing a database; determining any servers in a domain to which a server in the domain is coupled; and verifying that the server has only one couple to any other of the any servers in the domain.
In an exemplary embodiment, the method can further include maintaining only one couple to any other server of the any servers in the domain.
An exemplary embodiment of the present invention is directed to a system that is operative to provide discovery services for servers during a startup sequence including: a server in a domain having a processor, a memory coupled to the processor, a power supply operative to power on the server coupled to the processor, a socket operative to create a listener socket for the server to accept coupling requests from other servers; a registry operative to register server information for the server with a database; a query tool operative to search the database for other registered servers in the domain; a coupler operative to establish a couple to each of the other registered servers in the domain; and a validator operative to verify validity of the couple to each of the other registered servers including performing a handshake.
In an exemplary embodiment, the server information registered with the database can include an IP address; a listener port; a domain; a version number; or a server type.
In an exemplary embodiment, the coupler is operative to send a couple message from a coupling server of the other registered servers; receive the couple message by another server of the other registered servers; verify a version number of the couple message; verify that the couple message sent and received is a valid couple message; reply with a reply message to the couple message; or verify that the reply message contains a valid version number and server type.
In an exemplary embodiment, the coupler can be further operative to close the couple if the version numbers are not valid.
In an exemplary embodiment, the coupler can be further operative to close the couple if the server type is not valid.
In an exemplary embodiment, the coupler can be further operative to close the couple if the reply message is not received within a predetermined amount of time.
In an exemplary embodiment, the registry can be operative to register at least one of a server identifier (ID), a service type, and a message type supported by the server.
In an exemplary embodiment, the server can be a back end server (BES); a proxy gateway (PG); a message router (MR); or an HTTP Proxy BES.
An exemplary embodiment of the present invention is directed to a system operative to handle couple race conditions including a server including a processor; a memory coupled to the processor; wherein the server is operative to access a database; determine any servers in a domain to which a server in the domain is coupled; and verify that the server has only one couple to any other of the any servers in the domain.
In an exemplary embodiment, the server can be further operative to maintain only one couple to any other server of the any servers in the domain.
An exemplary embodiment of the present invention is directed to a computer program product embodied on a computer readable medium, the computer program product having program logic encoded therein, the program logic adapted to provide discovery services for servers during a startup sequence including program code means for enabling a computer to power on a server in a domain; program code means for enabling the computer to create a listener socket for the server to accept coupling requests from other servers; program code means for enabling the computer to register server information for the server with a database; program code means for enabling the computer to search the database for other registered servers in the domain; program code means for enabling the computer to establish a couple to each of the other registered servers in the domain; and program code means for enabling the computer to verify validity of the couple to each of the other registered servers including performing a handshake.
An exemplary embodiment of the present invention is directed to a computer program product embodied on a computer readable medium, the computer program product having program logic encoded therein, the program logic adapted to handle coupling race conditions including: program code means for enabling a computer to access a database; program code means for enabling the computer to determine any servers in a domain to which a server in the domain is coupled; and program code means for enabling the computer to verify that the server has only one couple to any other of the any servers in the domain.